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CONTENT DISTRIBUTION APPARATUS, CONTENT RECEIVING APPARATUS , AND 

CONTENT DISTRIBUTION METHOD 

BACKGROUND OF THE INVENTION 

5 

1 . Field of the Invention 

The present invention relates to a content distribution 
apparatus , a content receiving apparatus , and a content 
distribution method. More particularly, it relates to technology 
10 in real-time distribution of content via an open network such as 
the Internet , whereby protection is provided against content theft 
by third parties and unauthorized copying of content by a content 
recipient , thereby enabling transmission and reception of content 
data while considering copyright protection. 

15 

2. Description of the Related Art 

In recent years , the digitization of the home sound and image 
(audio/ visual; hereinafter abbreviated AV) environment, as 
exemplified by the start of digital broadcasts and the sales of 

20 digital AV equipment has gained much attention. Digital AV data 
enables diverse types of compression, is amenable to processing 
as multimedia data, tolerates unlimited playback without 
deterioration, and has other features which are expected to result 
in an expansion in its application in the future. 

25 On the other hand, digital AV data technology is accompanied 

by the problem of easy unauthorized copying of content. More 
specifically, any type of digital content can in principle be used 
to create a copy identical to the original and indefinitely durable , 
by means of bit copying, in the process of unauthorized content 

30 copying . 

A variety of technologies are being studied for the purpose 
of preventing unauthorized copying. One of these is the 139 4CP 
Content Protection System Specification being studied by the CPTWG 
(Content Protect ion Technical Working Group) . In this technology, 
35 an authentication procedure is performed beforehand between 

sending and receiving nodes for content (such as MPEG data) to 
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be transferred between nodes connected by the IEEE 1394 bus, to 
enable shared use of an encryption key (content key) . Thereafter, 
this encryption key is used to encrypt the content and then encrypted 
content is transferred, and it is not possible for nodes other 
5 than the nodes that performed the authentication procedure to 
decrypt the content. By doing this, because a node other than 
the authenticated nodes (that is, a third party node) does not 
know the encryption key, even the node were able to capture the 
transferred data (that is, the encrypted content data) , it would 

10 not be able to decrypt it. Nodes that can participate in this 
authentication procedure are limited to nodes that receive 
permission to do so by an authentication organization beforehand, 
thereby preventing an unauthorized node from obtaining the 
encryption key, and thus preventing unauthorized copying of 

15 content . 

The distribution of digital content is not , of course , limited 
to transfer via the IEEE 1394 bus , and general networks are expected 
to be used. The Internet is a strong candidate for building a 
technology infrastructure that is not wedded to public networks 

20 or physical/link networks. 

In conventional content distribution as practiced, however, 
digital content on the Internet {and in particular digital AV 
streams) wasmainly transferred in its raw fojnn by the RTP (Real-time 
Transport Protocol), without copyright protection provided by 

25 prevention of third-party theft and unauthorized copying by a 
recipient . 

SUMMARY OF THE INVENTION 

30 Accordingly, it is an object of the present invention, in 

consideration of the above-noted situation, to provide content 
distribution apparatus, a content receiving apparatus, and a 
content distribution method, which provide protection from copying 
when digital content is transferred on the Internet by real-time 

35 streaming. 

A feature of the present invention is that information with 
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regard to encryption and encoding etc, required to provide copy 
protection for digital content is efficiently appended as various 
headers to the content, making use of the characteristics of the 
Internet . 

5 One aspect of the present invention provides a content 

information distribution apparatus for distributing encrypted 
content information, via a network in accordance with a prescribed 
transport protocol, to other end apparatus in a communication 
authenticated by an authentication process including at least one 
10 procedure of an authentication procedure and a key exchange 
procedure, comprising: (a) a unit for encrypting content 
% information encoded by a prescribed encoding system; (b) a unit 

for generating an encryption attribute header including attribute 
information with regard to the encryption of the content 
15 information; (c) a unit for performing transport protocol 

processing required to transfer the content information and for 
generating a basic transport header to be added to the content 
information to which the encryption at tribute header has been added ; 
and (d) a unit for sending to the other end apparatus that is 
20 authenticated a packet including the basic transport header, the 
encryption attribute header, and the encrypted content information, 
wherein the encryption attribute header is set into an expansion 
transport header within a packet header of the packet or into a 
payload header within a payload to be encrypted of the packet. 
25 It is preferable that the encryption attribute header 

includes at least one of the existence or non-existence of 
encryption of the content information and the encryption system 
of the content information. 

It is preferable that the encryption attribute header 
30 includes a copy attribute field having a plurality of bits with 
regard to the number of copying of the content information. 

It is preferable that the encryption attribute header 
includes a counter field indicating a change in an encryption key. 
It is preferable that the unit (b) sets the encoding 
35 information, which indicates the encoding system for the content 
information into the expansion transport header or into the payload 
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header . 

It is preferable that the unit (c) further codes into the 
basic transport header at least information to the effect that 
there is a possibility that the content information is encrypted, 
5 and wherein the unit (b) codes into the expansion header at least 
information as to whether or not the content information to be 
transferred is encrypted - 

It is preferable that the unit (b) codes into the expansion 
header information as to whether or not the content information 
10 to be transferred is encrypted, 
^.^ The above-noted content information distribution apparatus 

5 can further comprising: (e) a unit for generating a content 

111 attribute header that includes content attribute information with 

regaird to content information, and for setting this content 
|3 15 attribute header into the expansion transport header or into the 
H payload header. 

The content attribute header need not be encrypted. 
}^ The unit (a) generates the encryption key based on an 

M identifier that uniquely identifies a storage medium sent from 

5 J- 20 the other end apparatus in the communication. 

Another aspect of the present invention provides a content 
13 information receiving apparatus authenticated by an 

authentication process including at least one procedure of an 
authentication procedure and a key exchange procedure and which 
25 receives encrypted content information via a network in accordance 
with a prescribed transport protocol, comprising: (aa) a unit for 
receiving from a sending apparatus a packet containing a basic 
transport header, an encryption attribute header including 
attribute information with regard to the encryption of the content 
30 information, and encrypted content information; (bb) a unit for 
referring to the basic transport header or encryption attribute 
header and judging whether or not the content information is 
encrypted or whether there is a possibility that the content 
information is encrypted; and (cc) a unit that, when a judgment 
35 is made by the unit (bb) that the content information is encrypted, 
decrypts the encrypted content information, based on the attribute 
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information with regard to encryption included in the encryption 
attribute header. 

It is preferable that the unit (bb), when there is a 
possibility that the content information is encrypted, refers to 
5 the encryption attribute header and judges whether or not the 
content information is enciiYpted. 

It is preferable that the unit (bb) refers to the basic 
transport header or to the encryption attribute header to make 
a judgment as to the encoding system of the content information. 

10 The above-noted apparatus can further comprising: (dd) a 

unit for referring to a received basic transport header and, when 
a prescribed delay time has elapsed or a prescribed number of packets 
have been discarded, requesting that the sending apparatus send 
a prescribed encryption parameter. 

15 Another aspect of the present invention provides a method 

of distributing encrypted content information, via a network in 
accordance with a prescribed transport protocol, to other end 
apparatus in a communication authenticated by an authentication 
process including at least one procedure of an authentication 

20 procedure and a key exchange procedure, comprising the steps of: 
(a) encrypting content information encoded by a prescribed encoding 
system; (b) adding an encryption attribute header including 
attribute information with regard to the encryption of the content 
information to the encrypted content information; (c) adding a 

25 content attribute header indicating attributes of the content 
information to content information to which the encryption 
attribute header has been added; (d) performing transport protocol 
processingrequiredto transfer the content information, and adding 
a basic transport header to content information to which the content 

30 attribute header has been added; and (e) sending a packet including 
the basic transport header, the encryption attribute header, the 
content attribute header, and the encrypted content information 
to the other end authenticated apparatus, wherein the encryption 
attribute header is set into either an expansion transport header 

35 within a packet header of the packet, or into a payload header 
within an encrypted payload of the packet. 
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Another aspect of the present invention provides a method 
of distributing encrypted content information, via a network in 
accordance with a prescribed transport protocol , to other end 
apparatus in the communication authenticated by an authentication 
5 process including at least one procedure of an authentication 
procedure and a key exchange procedure, comprising the steps of: 
(a') adding a content attribute header indicating attributes of 
the content information to the content information to be 
transferred; (b' ) encrypting content information that are encoded 

10 by a prescribed encoding system and to which the content attribute 
header has been added; (c') adding to the encarypted content 
information an encryption attribute header including attribution 
information with regard to the encryption of the content 
information; (d*) performing transport protocol processing 

15 required to transfer the content information, and adding a basic 
transport header to content information to which the encryption 
attribute header has been added; and (e' ) sending a packet including 
the basic transport header, the encryption attribute header, the 
content attribute header, and the encrypted content information 

20 to the other end authenticated apparatus, wherein the encryption 
attribute header is set into either an expansion transport header 
within a packet header of the packet, or into a payload header 
within a payload to be encrypted of the packet. 

Another aspect of the present invention provides a method 

25 of receiving encrypted content information, via a network in 
accordance with a prescribed transport protocol, by an 
authentication process including at least one procedure of an 
authentication procedure and a key exchange procedure, comprising 
the steps of: (aa) receiving a packet including a basic transport 

30 header, an encryption attribute header including encryption 
attribute information with regard to the encryption of the content 
information, and encrypted content information; (bb) referring 
to the basic transport header and judging whether or not the content 
information is encrypted or whether or not there is a possibility 

35 that the content information is encrypted; (cc) referring to the 
encryption attribute header and extracting encryption attribute 
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information with regard to encryption of the content information; 
(dd) referring to an expansion transport header within a packet 
header of the packet and extracting content attribute information 
with regard to the content information; and (ee) in the case in 
which a judgment is made at (bb) that the content information is 
encrypted, decrypting the encrypted content information, based 
on the extracted encryption attribute information. 

Another aspect of the present invention provides a method 
of receiving encrypted content information, via a network in 
accordance with a prescribed transport protocol, by a 
authentication process including at least one procedure of an 
authentication procedure and a key exchange procedure, comprising 
the steps of: (aa' ) receiving a packet including a basic transport 
header, an encryption attribute header including encryption 
attribute information with regard to the encryption of the content 
information^ and encrypted content information; (bb' ) referring 
to the basic transport header and judging whether or not the content 
information is encrypted or whether or not there is a possibility 
that the content information is encrypted; (cc*) in the case in 
which a judgment is made at (bb') that the content information 
is encrypted, referring to the encryption attribute header and 
extracting encryption attribute information with regard to the 
encryption of the content information; (dd' ) in the case in which 
a judgment is made at (bb ' ) that the content information is encrypted, 
decrypting the encrypted content inf oirmat ion based on the extracted 
encryption attribute information; and (ee') referring to an 
expansion transport header within a packet header of the packet 
and extracting content attribute information with regard to the 
content information • 

Another aspect of the present invention provides a 
computer-readable recording medium for recording a program to be 
executed by a computer, the program performing distribution of 
encrypted content information, via a network in accordance with 
a prescribed transport protocol, to other end apparatus in a 
communication authenticated by an authentication process 
including at least one procedure of an authentication procedure 



and a key exchange procedure, the program comprising: (a) a module 
for generating an encryption attribute header including attribute 
information with regard to encryption of the content information; 
(b) amodule for performing transport protocol processing required 
5 to transfer the content information and for generating a basic 
transport header to be added to the content information to which 
the encryption attribute header has been added; and (c) a module 
for sending a packet including the basic transport header, the 
encryption attribute header , and the encrypted content information 

10 to the other end authenticated apparatus, wherein the encryption 
attribute header is set either into an expansion transport header 
within a packet header of the packet or into a payload header within 
a payload to be encrypted of the packet , 

Another aspect of the present invention provides a 

15 computer-readable recording medium for recording a program to be 
executed by a computer, the program performing receiving of 
encrypted content information, via a network in accordance with 
a prescribed transport protocol, by an authentication process 
including at least one procedure of an authentication procedure 

20 and a key exchange procedure , the program comprising: ( aa) a module 
for receiving from a sending apparatus a packet including a basic 
transport header, an encryption attribute header including 
attribute information with regard to encryption of the content 
information, and encrypted content information; (bb) referring 

25 to the basic transport header or the encryption attribute header 
and judging whether or not the content information is encirypted 
or whether there is a possibility that the content information 
is encrypted; and (cc) in the case in which a judgment is made 
bymodule (bb) that the content information is encrypted, decrypting 

30 the encrypted content information based on attribute information 
with regard to encryption included in the encryption attribute 
header . 

Other features and advantages of the present invention will 
become apparent from the following description taken in conjunction 
35 with the accompanying drawings . 
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BRIEF DESCRIPTION OF THE DRAWINGS 



The accompanying drawings, which are incorporated in and 
constitute a part of the specification, illustrate presently 
5 preferred embodiments of the invention, and together with the 
general description given above and the detailed description of 
the preferred embodiments given below, serve to explain the 
principles of the invention, wherein: 

Fig. 1 is a drawing showing an example of a configuration 
10 of a network associated with the first embodiment to the sixth 
embodiment of the present invention; 

Fig. 2 is a diagram showing an example of a sequence of content 
distribution in the first embodiment to the sixth embodiment of 
the present invention; 
15 Fig. 3 is a block diagram showing an example of the 

configuration of an MPEG distribution server according to the first 
embodiment of the present invention; 

Fig- 4 is a flowchart showing the procedure for content 
distribution processing in an MPEG distribution server according 
20 to the first embodiment of the present invention; 

Fig. 5 is a drawing showing a first example of a format of 
a code expansion header; 

Fig. 6 is a drawing showing a first example of the format 
of a header given by an RTP processor; 
25 Fig. 7 is a drawing showing a first example of a format of 

a transferred IP packet; 

Fig. 8 is a block diagram showing an example of the 
configuration of a receiving apparatus according to the first 
embodiment of the present invention; 
30 Fig. 9 is a flowchart showing the procedure for content 

receiving processing in a receiving apparatus according to the 
first embodiment of the present invention; 

Fig. 10 is a block diagram showing an example of the 
configuration of an MPEG distribution server according to the second, 
35 third, or fifth embodiment of the present invention; 

Fig. 11 is a drawing showing a second example of a format 
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of a header given by an RTP processor; 

Fig. 12 is a drawing showing the second example of the format 
of a transferred IP packets- 
Fig, 13 is a flowchart showing the procedure for content 
5 distribution processing in an MPEG distribution server according 
to the second embodiment of the present invention; 

Fig. 14 is a block diagram showing an example of the 
configuration of a receiving apparatus according to the second, 
third, or fifth embodiment of the present invention; 
10 Fig. 15 is a flowchart showing the procedure for content 

receiving processing in a receiving apparatus according to the 
second embodiment of the present invention; 

Fig. 16 is a drawing showing a third example of a format 
of a header given by an RTP processor; 
15 Fig. 17 is a drawing showing a third example of a format 

of a transferred IP packet; 

Fig. 18 is a block diagram showing an example of the 
configuration of an MPEG distribution server according to the fourth 
or sixth embodiment of the present invention; 
20 Fig. 19 is a drawing showing a fourth example of a format 

of a header given by an RTP processor; 

Fig. 20 is a drawing showing a fourth example of a format 
of a transferred IP packet; 

Fig. 21 is a flowchart showing a procedure for content 
25 distribution processing in an MPEG distribution server according 
to the fourth embodiment of the present invention; 

Fig. 22 is a block diagram showing an example of the 
configuration of a receiving apparatus according to the fourth 
or sixth embodiment of the present invention; 
30 Fig. 23 is a flowchart showing a procedure for content 

receiving processing in a receiving apparatus according to the 
fourth embodiment of the present invention; 

Fig, 24 is a drawing showing a fifth example of a format 
of a header given by an RTP processor; 
35 Fig, 25 is a drawing showing a second example of a format 

of a code expansion header; 
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Fig. 26 is a drawing showing a fifth example of a format 
of a transferred IP packet; 

Fig. 27 is a drawing showing a sixth example of a format 
of a header given by an RTF processor; 
5 Fig. 28 is a drawing showing a sixth example of a format 

of a transferred IP packet; 

Fig. 29 is a drawing showing an example of the configuration 
of a network according to the seventh embodiment of the present 
invention; 

10 Fig, 30 is a drawing showing an example of the sequence of 

content distribution according to the seventh embodiment of the 
present invention ; 

Fig. 31 is a block diagram showing an example of the 
configuration of an MPEG distribution server according to the 
15 seventh embodiment of the present invention; 

Fig. 32 is a drawing showing a seventh example of a foirmat 
of a transferred IP packet; 

Fig. 33 is a drawing showing a seventh example of a format 
of a header given by an RPT processor; 
20 Fig. 34 is a block diagram showing an example of the 

configuration of a receiving apparatus according to the seventh 
embodiment of the present invention; and 

Fig. 35 is a drawing showing an example of the sequence of 
content distribution according to the eighth embodiment of the 
25 present invention. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Embodiments of a content distribution apparatus, a content 
30 receiving apparatus, and a content distribution method according 
to the present invention are described in detail below, with 
reference to Fig. 1 through Fig. 35. 

First Embodiment 

35 The first embodiment of a content distribution apparatus, 

a content receiving apparatus, and a content distribution method 
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according to the present invention is described in detail below, 
with reference to Fig, 1 through Fig, 9, 

Fig. 1 shows an example of the configuration of a content 
distribution system according to this embodiment of the present 
5 invention. In Fig. 1, an MPEG4 distribution server 101 and a 
receiving apparatus 102 according to this embodiment are connected 
to the Internet 103, MPEG4 AV stream data being securely 
communicated between the MPEG4 distribution server 101 and the 
receiving apparatus 102, via the Internet 103. Of course, other 
10 MPEG4 distribution servers and receiving apparatuses and other 
types of equipment can additionally be connected to the Internet 
103. 

In the description of embodiments to follow, while the type 
of data is MPEG (Motion Picture Experts Group) 4, it will be 
15 understood that the present invention is not restricted to 

application to this type of data, and can be applied to other data 
types as well. 

The MPEG4 distribution server 101 performs distribution of 
MPEG4 data to the receiving apparatus 102. MPEG4 data is 

20 distributed not in the form of file transfer, but rather as data 
stream. The MPEG4 data that is to be copyright protected is 
distributed in encrypted form. When doing this , an authentication 
procedure or key exchange procedure is performed between the MPEG4 
distribution server 101 and the receiving apparatus 102. 

25 The sequence of this procedure is illustrated by example 

in Fig. 2. 

Fig, 2 shows the sequence of content layer encryption and 
authentication, and it should be noted that security in layers 
such as the IP layer and transport layer and authentication 
30 procedures in those layers have been omitted from this drawing, 
as has the procedure for assessing charges at the content layer, 
which is performed earlier ( although there are cases in which charge 
assessment and authentication/encryption at other layers are not 
performed) . 

35 Consider the case in which the receiving apparatus 102 makes 

a request to the MPEG4 distribution server 101 for distribution. 
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In this case, the first authentication request is sent from the 
receiving apparatus 102 {S201) . In this authentication request, 
there can also be a simultaneous exchange of a certificate 
(equipment certification) that is received by the apparatus 
5 (receiving apparatus 102) from a certification organization, the 
certificate certifying that the equipment is capable of performing 
transfer of copyright protected content. 

The "equipment ID" that is used in the equipment certification 
can be an IP address, and in the case in which the IP address is 

10 given by aDHCP (Dynamic Host Configuration Protocol) server, there 
is a possibility that this value will differ each time the apparatus 
is booted. Because of this situation, it is possible to use as 
the "equipment ID" for equipment certification the MAC address 
of the equipment, or the EUI64 address, or an address created by 

15 adding to these address a partial module number. It is further 
possible to use as the "equipment ID" the CPU ID number of the 
apparatus, or the MPEG4 decoder ID number or the like, which 
(ideally) is a value that is unique worldwide (or that can be expected 
to be unique or almost unique within the region). 

20 An MPEG4 distribution server 101 that receives a message 

from the receiving apparatus 101, performs a response to the 
authentication request and perfoarms exchange of a certificate 
(equipment certification) (S202). 

Next, the MPEG4 distribution server 101 and the receiving 

25 apparatus 102 perform a process that generates an authentication 
key, for the purpose of generating a common authentication key 
{S20 3) • Details of this procedure can be the same as , for example, 
the IEEE 1394 copy protection key generation process. When this 
process is completed, the MPEG4 distribution server 101 and the 

30 receiving apparatus 102 can possess a common authentication key 
Kauth, which is not knowable to a third party. 

Next, the MPEG4 distribution server 101 sends G(Kx, Kauth) 
which is generated by certain function G with the use of an exchange 
key Kx, the authentication key Kauth as arguments, and a random 

35 number Nc to the receiving apparatus 102 (S204, S205), At the 
receiving apparatus 102, reverse function of G(Kx, Kauth) is 
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calculated so as to extract the exchange key Kx, 

At this point in time, the MPEG4 distribution server 101 
and the receiving apparatus 102 share the three values of 
authentication key Kauth, exchange key Kx, and the random number 
5 Nc. 

At this point, the encryption key (content key) Kc, which 
is the encryption key for encrypting the MPEG4 data to be sent 
by the MPEG4 distribution server 101 and for the receiving apparatus 
102 to decrypt the received encrypted MPEG4 data (that is the shared 

10 key) , is calculated in the MPEG4 distribution server 101 and the 
receiving apparatus 102, respectively, by using one and the same 
pre-established function J, as a function of part of the above-noted 
value. For example, the calculation is made as Kc=J[Kx, f(EMI), 
Nc] , in which EMI indicates the copy attribute for the data (content ) , 

15 which expresses such attributes as the data being copiable without 
limit, the data being copiable only 1 time, the data being copiable 
only 2 times, the data being uncopiable under any conditions, or 
the data being already copied and therefore not further copiable. 
f (EMI) is obtained by transforming the attribute value of EMI with 

20 the use of certain specific function f , These functions J and 
f can also be kept maintained as secret with respect to the outside. 

After the encryption key (content key) Kc is generated, the 
MPEG4 distribution server 101 encrypts the content (MPEG4 data) 
using the encryption key Kc, and sends the encrypted content to 

25 the Internet (S206, S207, .,.). 

As will be described below, because the encrypted content 
is in the form of AV stream data transferred in real time over 
the Internet, in the first embodiment of the present invention 
RTP (Real-time Transport Protocol) is used as the transport 

30 protocol. 

It is also possible to make the encryption key Kc vary with 
time (that is, have its value change with the passage of time). 

For example, if the elapse of a prescribed amount of time 
(which can be a fixed amount of time, or a variable amount of time) 
35 from the previous change is recognized, the value of the variable 
Nc is incremented, and the above-noted function J is used to 
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calculate the encryption key Kc. When this is done, the timing 
of updating of the encryption key Kc value (or the data at the 
point at which the encryption key Kc is to be updated) must be 
recognized synchronously at the sending and receiving sides. For 

5 this reason, regions such as Even/Odd field is provided in the 
transferred MPEG4 data (AV data), and the point at which there 
is a change in the field is established as the point at which the 
value of the variable Nc, that is, the value of the encryption 
key Kc is changed, so that data after the field change point is 

10 encrypted with the updated encryption key Kc. 

The MPEG4 distribution server 101 monitors the above-noted 
elapse of time and , when the timing for the updating of the encryption 
key Kc is detected, the value of the variable Nc is incremented 
and the encryption key Kc is calculated again, the recalculated 

15 value of the encryption key Kc being used to encrypt the MPEG4 
data that is to be sent , the Even/Odd field value being incremented , 
and transmission being performed. Thereafter, until the timing 
for the next updating, this updated encryption key Kc is used to 
perform encryption . 

20 At the receiving apparatus 102, the received Even/Odd field 

value is monitored, comparing the value with the immediately 
previously received value and, if the value is detected as being 
different from the immediately previously received value, the value 
of the variable Nc is incremented, and the value of encryption 

25 key Kc is recalculated, the encryption key Kc after this 

recalculation being used in decrypting received encrypted data. 
Thereafter, until the next change in the Even/Odd field value is 
detected, this value of encryption key Kc is used to perform 
decryption. 

30 In this manner, encrypted MPEG4 data is transferred between 

the MPEG4 distribution server 101 and the receiving apparatus 102 . 

Fig. 3 shows an example of the internal configuration of 
the MPEG4 distribution server 101. 

As shown in Fig, 3, the MPEG4 distribution server 101 of 
35 this embodiment comprises a MPEG data generator 301, a data 

encryptor 302, an RTP processor 303, an RTCP transmitter 307, a 
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TCP/IP and UDP/IP processor 308, a link/physical layer processor 
309, an RCTP receiver/interpreter 310, and an authentication/key 
exchange processor 311. The RTP processor 303 includes an 
encryption expansion header adding unit 304, an MPEG4 expansion 
5 header adding unit 305, and an RTP basic header adding unit 306, 
and performs processing related to the RTP. 

Next , the procedure for processing the content distribution 
in the MPEG4 distribution server 101 according to the first 
embodiment is described below, with reference to Fig. 4. 
10 Processing related to authentication and encryption in the 

sequence of Fig. 2 (processing from S201 to S205) and processing 
related to the above-described updating of the encryption key is 
performed by the authentication/key exchange processor 311 . This 
processing can be performed before or after the sending of content 
15 to the receiving apparatus 102. 

The inputted AV information (for example, an analog signal) 
is compressed to MPEG4 data by the MPEG4 data generator 301. 

When this is done, if MPEG attribute information such as 
the location of I pictures (intra-coded pictures) and the encoding 
20 rate are sent simultaneously with the MPEG4 data to notify the 
receiving side, playback (decoding) at the receiving side is 
facilitated. In particular on the Internet, where such things 
as discarded and delayed packets and a change in the sequence of 
arrival of packets can occur, this attribute information is 
25 essential to achieve high-quality playback at the receiving side. 
For example, in the case of MPEG4 in the first embodiment, 
information about , for example , the VOP header corresponds to these 
attributes. Cases can be envisioned in which information with 
regard to the MPEG4 system, for example transmission of 
30 synchronization information at a sync layer, information for 
multiplexing when sending a plurality of MPEG4 streams in 
multiplexed format , or information with regard to initial and latest 
values of object descriptors is required. For this reason, when 
sending AV data by RTP, the above-noted information is coded into 
35 the RTP expansion header or into the payload header of the RTP 
payload (that is, user area), so that the MPEG attribute information 
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is sent along with the AV data. 

In the first embodiment, this MPEG attribute information 
is sent in the form of an RTP expansion header. That is, it is 
sent as an RTP expansion header of the ID type of MPEG4 expansion 
header. For this reason, required information with regard to 
encoding is sent from the MPEG4 data generator 301 as notification 
to the MPEG4 expansion header adding unit 305. 

Next , the MPEG4 data outputted from the MPEG4 data generator 

301 is encrypted by the data encryptor 302 (step S401 in Fig. 4). 
When this is done, the encryption key may be the above-noted 
time- variant encryption key Kc. With regard to the encryption 
processing as well, a variety of attribute information can be 
envisioned . In the first embodiment . an RTP expansion header whose 
ID type indicates the encryption expansion header is added by the 
encryption expansion header adding unit 304 ( step S403 ) . For this 
reason, information required for the generation of an encryption 
expansion header is sent as notification from the data encrypter 

302 to the encryption expansion header adding unit 304. 

In order to perform the above-noted encryption processing, 
at the authentication/key exchange processor 311 when the timing 
for updating the encryption key Kc is reached, Nc is incremented 
and the above -de scribed function J is used to generate a new 
encryption key Kc which is passed to the data encrypter 302 . Along 
with this, the value of Even/Odd field is incremented and passed 
to the data encrypter 302. The value Even/Odd field is passed, 
as noted above, from the data encrypter 302 to the encryption 
expansion header adding unit 304 . 

Fig. 5 shows an example of an encryption expansion header. 
The encryption expansion header has a expansion header type field, 
a encryption on/off field, encryption type indication field, an 
encryption mode indicator (EMI) field, and an Even/Odd field. 

The expansion header type field is for coding information 
that indicates the type of corresponding expansion header. In 
this case, information that indicates the encryption expansion 
header is coded into the expansion header type field. 

The encryption on/off field is a field for coding information 
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indicating whether or not the data transferred in the corresponding 
RTP packet is encjrypted. 

The encryption type indicator field is a field for coding 
the type of encryption used with respect to data transferred in 
5 an RTP packet. For example, in Fig. 5, information is described 
that indicates "an M6 encryption type". 

The encryption mode indicator (EMI) field is a field for 
coding the above-noted copy attribute value EMI. 

The Even/Odd field, as noted above, is a field for notifying 

10 the receiving side from the sending side of the timing of updating 
of the encryption key. 

Although in the example shown each field has 8 bits, there 
is no restriction to the number of bits, and the niimber of bits 
can be appropriately established as desired. 

15 When AV data is encrypted and sent to the receiving side, 

if it is desired to perform such trick play as fast-forwarding, 
or sending of partial static images, there are cases in which 
processing at the receiving side becomes difficult. This is 
because it is difficult to perform a task such as sending just 

20 a part of an encrypted AV data stream (for example, because the 
Nc value would not be incremented but would rather skip over a 
number of values ) . For this reason , in certain cases it is desirable 
to send AV data to the receiving side without encrypting it. In 
such cases, it is necessary to notify the receiving side by 

25 information as to whether or not the AV data has been encrypted. 
The above-noted encryption on/off field is provided for such 
purposes . 

Additionally, on the Internet there is the possibility that 
one stream will use one encryption type and another stream use 
30 a different encryption type. In such cases, if there is a field 
that indicates to what type of encryption the AV data has been 
subjected, the receiving side can examine this field so as to select 
a proper decryption engine for describing the data. The 
above-noted encryption type indicator field is provided for this 
35 type of purpose. 

As shown in Fig. 5, the encryption mode indicator (EMI) field 
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is 8 bits rather than the 2 bits that are used in the case of IEEE 
1394, This is in order to establish the freedom to select a value 
of N used to give notification of the specification of the number 
of copies N of the AV data that are to be permitted, and for cases 
5 in which a special type of copying (for example, permitting copying 
only when some condition is satisfied), in which case this field 
must be able to take a larger number of values than would be possible 
with 2 bits . 

As shown in Fig, 5, in the Even/Odd field, in contrast to 

10 the 1 bit used in IEEE 1394, there are 8 bits provided. This is 
because 1 bit would not allow enough information for the Internet, 
in which as noted above it is possible to have discarded or delayed 
packets and an altered sequence of packet arrivals. Thus, for 
example, on the Internet a case can be envisioned in which, with 

15 the Even/Odd bit 1 as shown at stepS20 7, all the packets are discarded. 
In this case, if the Even/Odd field were to be just 1 bit, the 
Even/Odd field would return to 0 at the next packet, so that as 
seen from the receiving side the condition in which the Even/Odd 
bit is 0 is continuing (that is, not changing). Thus, although 

20 Nc should actually be incremented by 2, if the Even/Odd bit value 
is not changed, the Nc value is not incremented, thereby preventing 
generation of the correct encryption key. Because of this 
situation, more than 2 bits, for example 8 bits, are provided in 
the Even/Odd field, so that even if packet discarding and delay, 

25 or resequencing of packet arrival occurs , as it can on the Internet , 
it is possible to perfoorm appropriate processing on the receiving 
side. 

In the first embodiment of the present invention, data 
encryption is performed only with respect to MPEG4 data itself. 

30 and not with respect to the MPEG4 expansion header. Because the 
MPEG4 expansion header is not content that need to be copyright 
protected, but is rather used on the receiving side before the 
MPEG4 data itself is used, enabling it to omitted from the data 
that is encrypted. 

35 In the RTP processor 303, an encryption expansion header 

is added to the MPEG4 data by the encryption expansion header adding 



19 



unit 304, an MPEG4 expansion header is added to the MPEG4 data 
by the MPEG4 expansion header adding unit 305 (step S405 in Fig. 
4) , and an RTP basic header is added to the MPEG4 data by the RTP 
basic header adding unit 306 (stepS407), the ultimate result being 

5 the addition of the RTP header such as shown in Fig- 6. The 
encryption expansion header is generated based on information from 
the data encrypter 302 , and the MPEG4 expansion header is generated 
based on information from the MPEG4 data generator 301. The RTP 
header has elements that are basic parameters required for AV data 

10 transfer via the Internet, such as a time stamp and a sequence 
number (for details, refer to RFC 1889). 

Encrypted MPEG4 data to which the RTP header has been added 
is sent to the Internet 103 by the TCP/IP and*'UDP/IP processor 
308 as an IP packet as shown in Fig. 7, via the link/physical layer 

15 processor 309. 

Next, the configuration of the receiving apparatus 102 and 
the procedure for processing therein will be described. 

Fig. 8 shows the internal configuration of the receiving 
apparatus 102. 

20 As shown in Fig. 8, the receiving apparatus 102 according 

to the first embodiment comprises a link/physical layer processor 
701, a TCP/IP and UDP/IP processor 702, an RTP processor 703, a 
data encryptor/decryptor 707, an MPEG4 data decoder 708 , areceiving 
condition interpreter 709, an RTCP transmitter 710, and an 

25 authentication/key exchange processor 711 . The RTP processor 703 
includes an RTP basic header receiver/ interpreter 704, an MPEG4 
expansion header receiver/interpreter 705, and an encryption 
expansion header receiver/interpreter 7 06, and performs 
processing related to the RTP. 

30 Fig. 9 shows a procedure for encrypted content receiving 

processing performed by the receiving apparatus 102 of the first 
embodiment of the present invention. 

Processing related to authentication and encryption of the 
sequence of Fig. 2 (processing from S201 to S205) and processing 

35 related to encryption key updating is performed by the 
authentication/key exchange processor 711. 
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The receiving apparatus 102 basically performs processing 
in a sequence that is the reverse of the processing performed by 
the MPEG4 distribution server 101. 

Specifically, MPEG4 data (encrypted data with an added RTP 
6 header) transferred via the Internet 103 passes through the 
link/physical layer processor 701 to the TCP/IP and UDP/ IP processor 
702 and is then inputted to the RTP processor 703 (step S901 in 
Fig. 9). 

At the RTP processor 703 , the RTP basic header is interpreted 

10 by the RTP basic header receiver /interpreter 704 (step S903 in 
Fig. 9), the MPEG4 expansion header is interpreted by the MPEG4 
expansion header receiver/interpreter 705 (Step S905), and the 
encryption expansion header is interpreted by the encryption 
expansion header receiver/interpreter 706 (Step S907). 

15 Information required for decoding is sent as notification from 
the MPEG4 expansion header receiver/interpreter 705 to the MPEG4 
data decoder 708, and information required for decryption is sent 
from the encryption expansion header receiver/ interpreter 706 to 
the data encyptor/decryptor 707. 

20 The encrypted data stored in the RTP payload is passed from 

the RTP processor 703 to the data encryptor/decryptor 707. The 
data encryptor/decryptor 707 performs decryption of data, based 
on information from the encryption expansion header 
receiver/interpreter 706 . 

25 The encryption key used in decryption is the above -de scribed 

time-variant encryption key Kc. That is, the data 
encryptor/decryptor 707 refers to a value of the encryption on/off 
field of the encryption expansion header sent as notification from 
the encryption expansion receiver/interpreter 706, so as to learn 

30 that the received data is encrypted (as a result of which the 
decryption thereof is determined) , after which the Even/Odd field 
is referenced and a comparison is made between the value thereof 
and a previously received value . If the value had been an increment , 
it is known that the encryption key is to be updated (but if the 

35 values are the same, the encryption key will not be updated) . Then, 
the fact that the encryption key is to be updated is notified to 
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the authentication/key exchange processor 711 from the data 
encryptor/decryptor 707, and in the authentication/key exchange 
processor 711 since the timing for updating the encryption key 
Kc has been reached, Nc is incremented and the above-noted function 
5 J is used to generate a new encryption key Kc, which is passed 
to the data encryptor/decryptor 70 7. 

Decrypted MPEG4 data is passed from the data 
encryptor/decryptor 707 to the MPEG4 data decoder 708. The MPEG4 
data decoder 708 decodes this MPEG4 data, based on information 
10 from the MPEG4 expansion header receiver/ interpreter 705, and 
outputs the results as an AV output data (for example, an analog 
signal) . 

In the above, the RTP has associated with xt RTCP (Real-time 
Transport Control Protocol) • RTCP monitors the RTP sequence 

15 number and time stamp and has the function of notifying the sending 
side (in the first embodiment, the MPEG4 distribution server 101) 
from the receiving side (in the first embodiment, the receiving 
apparatus 102) with regard to the receiving condition (packet 
discarding rate, packet transmission delay time, and the like). 

20 This is performed by the receiving condition interpreter 709 and 
the RTCP transmitter 710. 

The MPEG4 distribution server 101 receives this RTCP packet 
at the RTCP receiver /interpreter 310 and, if necessary, can apply 
feedback to the MPEG4 data generator 301, to attempt to achieve 

25 optimization. For example, in the case in which there is a great 
amount of packet discarding, network crowding can be envisioned ^ 
in response to which the bit rate of the MPEG4 data generation 
can be lowered by feedback - 

The RTCP transmitter 307 of the MPEG4 distribution server 

30 101 transmits information required for RTCP. 

On the other hand, as described above, in the receiving 
apparatus 102 based on the results of monitoring the Even/Odd field 
included in the encryption expansion header of the received packet , 
the value of the variable Nc used in the calculation of the encryption 

35 key Kc is changed. Therefore, if it is not possible for the sending 
side to reliably inform the receiving side that the value of Nc 
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has been updated , the receiving side cannot calculate the encrypt ion 
key Kc, thereby making it impossible to decrypt the arriving 
encrypted data. 

Because the Internet is intrinsically a network on which 
5 discarding of packets can occur, it is not guaranteed that the 
meaning of the Even/Odd field value (timing of incrementing) will 
be accurately informed to the other apparatus in a communication 
link (particularly in the case in which there are few bits in the 
Even/Odd field) • Because of this situation, in the case in which 
10 the receiving apparatus 102 wishes to know the precise value of 
Nc, it can be provided with the option to issue a request to the 
O sending apparatus (in this embodiment, the MPEG4 distribution 

:5 server 101) for the Nc value. 

yj As an example of a case in which the receiving apparatus 

15 102 wishes to know the precise Nc value , consider the case in which 
there is more skipping than expected in the time stamp or the sequence 
Ifl number of the RTP basic header, in which case one solution 

s envisionable is that of sending a packet to the sending side to 

request the value of Nc. This is because a skip greater than a 
f?l 20 pre-established limit could mean the possibility that the Even/Odd 
O bit value has changed. This processing is performed by the 

O authentication/key exchange processor 311 of the MPEG4 

distribution server 101 or the authentication/key exchange 
processor 711 of the receiving apparatus 102. By doing this, even 
25 in the event that synchronization of the Even/Odd bit is lost between 
the MPEG4 distribution server 101 and the receiving apparatus 102 , 
it is possible to perform appropriate recovery processing. 
Furthermore, in the case in which there is notification of Nc value 
from the MPEG4 distribution server 101 to the receiving apparatus 
30 102, it is possible to simultaneously send the time stamps and 
sequence numbers of the corresponding RTP, expansion header, or 
payload header as notification. 

A case can be envisioned in which distributed data is 
accumulated in the receiving apparatus (or in some form of storage 
35 medium, such as DVD-RAM or the like, installed in the receiving 
apparatus), in which case the distributed data can be stored as 
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is in the form of encrypted data, and the corresponding encryption 
key Kc stored together therewith. 

Second Embodiment 
5 Next, the second embodiment, in which there is a variation 

of the packet format in the first embodiment, is described below, 
with reference to Fig, 10 through Fig, 15. Because the basic 
configuration and operation of the second embodiment is the same 
as that of the first embodiment, the description that follows 
10 focuses on the differences introduced with the second embodiment 
compared to the first embodiment. 

The difference in the second embodiment with respect to the 
first is that, whereas in the first embodiment an encryption 
expansion header andMPEG4 expansion header were added as expansion 
15 header in an RTF header {Fig. 6 and Fig. 7 ) , in the second embodiment 
the encryption expansion header is added as the expansion header 
in the RTP header and the MPEG4 expansion header is added as a 
payload header to the RTP payload (Fig. 11 and Fig. 12). 

The overall network configuration according to the second 
20 embodiment is similar to that of the first embodiment (Fig. 1). 
The processing sequence is also similar to that of the first 
embodiment (Fig. 2). The encryption expansion header format is 
also similar to that of the first embodiment (Fig. 5), 

Fig. 10 shows an example of the configuration of an MPEG4 
25 distribution server 101 according to the second embodiment. In 
this embodiment, because the MPEG4 expansion header is provided 
as a payload header for the RTP payload , the processing for applying 
the MPEG4 header is removed from the RTP processing, so that the 
MPEG4 expansion header adding unit 305 of Fig. 3 is removed from 
30 within the RTP processor 305 and placed outside, this becoming 
the MPEG4 payload header adding unit 315, which is different than 
in the first embodiment. 

Fig. 11 shows the format of the RTP header used when sending 
encrypted AV data in the second embodiment. In the second 
35 embodiment, a payload type field that indicates an attribute of 
data that is transferred by an RTP packet (for example, encoding 
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system) is provided ia the RTF basic header. In the second 
embodiment, for example, if the transferred data is encrypted MPEG4 
data, this field will be coded with information indicating "the 
data is encrypted MPEG4 data". The receiving apparatus 102 can 
5 know that transferred data is encrypted MPEG4 data with reference 
to this field. 

Additionally in the second embodiment , the RTF basic header 
is provided with an X bit field that indicates whether or not there 
is an expansion header added to the RTF header. In the second 

10 embodiment , the arrangement is that a bit indicating "the existence 
of an expansion header" is set. 

Fig. 12 shows the overall format of an IF packet transferred 
over the Internet by the second embodiment. 

Fig. 13 is a flowchart shows the procedure for processing 

15 of content distribution in the second embodiment of the present 
invention. In this second embodiment, first the MPEG4 pay load 
header adding unit 315 adds an MPEG4 pay load header to the content 
(step S400) , the step S405 shown in Fig. 4 not being carried out. 
The processing of the other steps S401, S403, S407 , and S409 is 

20 similar to the processing as described with regard to the first 
embodiment. However, the header has the above-noted information 
set into it. 

Next, the receiving apparatus 102 according to the second 
embodiment is described below. 

25 Fig. 14 shows an example of the configuration of the receiving 

apparatus 102 of the second embodiment • Similar to the above-noted 
MPEG4 distribution server 101 , the processing of theMFEG4 expansion 
header is moved to outside of the RTF processor, the MPEG4 expansion 
header receiver/ interpreter 705 of Fig. 8 being moved from inside 

30 the RTF processor 703 to outside, this becoming the MPEG4 payload 
header receiver /interpreter 715, which is different than in the 
first embodiment. 

Fig. 15 is a flowchart showing the procedure for receiving 
processing in a receiving apparatus 102 according to the second 

35 embodiment . 

At the receiving apparatus 102, first a packet is received 
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(step S901) , and at the RTF basic header receiver/ interpreter 704 
it is learned that the received data is encrypted MPEG4 data and 
that an expansion header has been added to the RTF header (step 
S903). Then, at the expansion header receiver/interpreter 706 
5 it is learned that the expansion header is an encryption expansion 
header, and possible to learn from the encryption expansion header 
the encryption system and whether or not there is updating of the 
encryption key (step S907) . Then, similar to the case of the first 
embodiment , at the data encryptor/decryptor 707 the encrypted MPEG4 
10 data is decrypted (step S909), and at the MFEG payload header 
receiver/ interpreter 715 the MFEG4 payload header is interpreted 
O (step S910), and further, similar to the first embodiment, at the 

% MPEG4 data generator 708 , MPEG4 data is decoded, based on the results 

y of the above interpreting, the results being outputted as an AV 

Cl 15 output data (for example, an analog signal), 

1 1 1 

In this second embodiment, in the case in which the payload 
type field is coded with information that includes notification 
Hi of encryption, the enciryption on/off field of the encryption 

rz, expansion header need not be referenced, and in the case in which 

20 the payload type field is coded with information that includes 
O notification of the encryption, this can be taken as a notification 

Q of the possibility of encryption, so that encryption on/off field 

in the encryption expansion header can be used for the final 
determination of whether or not there is encryption. 

25 

Third Embodiment 

Next, the third embodiment of the present invention is 
described in detail below, with reference to Fig. 16 and Fig. 17. 
In this embodiment, the description will focus on differences with 
30 respect to the second embodiment. 

The configuration and processing in the third embodiment 
are similar to those of the third embodiment. 

Fig. 16 shows the format of the RTF header format used in 
transmitting encrypted AV data in the third embodiment, and Fig. 
35 17 shows the overall IP packet format transferred via the Internet 
in the third embodiment . 
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Specifically, whereas in the second embodiment, in the 
payload type field within the RTF basic header information was 
coded that provides notification of the existence of encryption 
or the possibility of encryption, such as "encrypted MPEG4 data", 
5 in the third embodiment, only "MPEG4'' is coded, and information 
including notification of encrypting or the possibility thereof 
is not coded in the payload type field. 

In the third embodiment, therefore, while the receiving 
apparatus 102 can refer to the payload type field to know that 

10 the received data is MPEG4 data, recognition with regard to whether 
or not there is eacryption is done by referencing the RTF expansion 
header (the encryption expansion header) of the RTF header. 

In the receiving apparatus 102, at the RTF basic header 
receiver/interpreter 704 it is learned that the received data is 

15 MFEG4 data, and that an expansion header is added to the RTF header. 
Then, at the encryption expansion header receiver /interpreter 706, 
it is learned that the expansion header is an encryption expansion 
header, and it is possible to learn from the encryption expansion 
header whether or not there is encryption and whether or not the 

20 encryption key is updated. Thereafter, the processing is the same 
as in the second embodiment . 

Fourth Embodiment 

Next, the fourth embodiment of the present invention is 
25 described below with reference to Fig. 18 to Fig. 23, focusing 
on the difference between it and the second embodiment. 

The difference between the fourth embodiment and the second 
embodiment is that , whereas in the second embodiment the encryption 
expansion header is added to the expansion header of the RTF header 
30 and the MPEG4 expansion header is provided as a payload header 
of the RTF payload (Fig. 11 and Fig. 12) , in the fourth embodiment, 
both the encryption expansion header and the MPEG4 expansion header 
are provided as a payload header in the RTF payload (Fig. 19 and 
Fig. 20). 

35 The overall configuration of a network according to the fourth 

embodiment is similar to that of an above-noted embodiment (Fig. 
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1) , and the processing sequence is also similar to an above-noted 
embodiment ( Fig . 2 ) . The format of the encryption expansion header 
(encryption payload header in the fourth embodiment) is also the 
same as described above (Fig, 5). 
5 Fig. 18 shows an example of the configuration of an MPEG4 

distribution server 101 according to the fourth embodiment. In 
this embodiment, because the encryption expansion header added 
to the MPEG4 expansion header is also provided as a payload header 
in the RTP payload, the processing for the encryption expansion 

10 header is placed outside the RTP processor, and the encryption 
expansion header adding unit 304 of Fig. 10 is also moved from 
within the RTP processor 304 to outside, this serving as the 
encryption payload header adding unit 314, which is a difference 
with respect to the second embodiment. 

15 Fig. 21 is a flowchart showing the procedure for content 

distribution processing according to the fourth embodiment- In 
the fourth embodiment , in place of step S403 of Fig. 13, an encryption 
payload header adding unit 314 adds an encryption payload header 
to the encrypted MPEG4 data (step 403b) , The processing at other 

20 steps S400, S401, S407, and S409 are similar to that described 
with regard to the above embodiment , with the exception that the 
above-noted information is set into the header. 

Fig. 19 shows the format of the RTP header used in transmission 
of encrypted AV data in the fourth embodiment. With regard to 

25 the payload type field, the fourth embodiment is similar to the 
second embodiment. The function of the X bit field is similar 
to that in the second embodiment, and in this embodiment the 
arrangement is that a bit indicating "no expansion header (no RTP 
expansion header)" is set. 

30 Fig. 20 shows the overall format of an IP packet transferred 

via the Internet in the fourth embodiment. 

Fig. 22 shows an example of the configuration of a receiving 
apparatus 102 according to the fourth embodiment. Similar to the 
case of the above-noted MPEG4 distribution server 101, the 

35 processing of the encryption expansion header is moved to outside 
the RTP processor, and the encryption expansion header receiver 
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/interpreter 706 of Fig. 11 is moved from within the RTP processor 
703 to outside, this serving as the encryption payload header 
receiver/ interpreter 716, which is a difference with respect to 
the second embodiment, 
5 Fig. 23 shows the procedure for receiving processing in the 

receiving apparatus 102 in the fourth embodiment . In the receiving 
apparatus 102, first a packet is received (step S901) , and at the 
RTP basic header receiver /interpreter 704 it is learned that the 
received data is encrypted MPEG4 data, and learned that no expansion 

10 header is added to the RTP header ( step S903 ) . In this embodiment , 
subsequent processing is processing for the payload. First at 
the encryption payload receiver/interpreter 716 it is learned that 
the payload is an encryption expansion header, and it is also 
possible to learn from the encryption payload header such 

15 information as the encryption system and whether the encryption 
key is updated (step S907b) . Subsequent processing is similar 
to the case of the second embodiment, the encrypted MPEG4 data 
being decrypted at the data encryptor/decryptor 707 (step S909) , 
the MPEG4 payload header being interpreted at the MPEG4 payload 

20 header receiver/interpreter 715 (step S910) , the MPEG4 data being 
decoded at the MPEG4 data generator 708, based on the above 
interpretation results, and the results of this being output as 
an AV output data (for example, an analog signal). 

Similar to the case of the second embodiment, in the fourth 

25 embodiment in a case in which information including notification 
of encryption is coded into the payload header, it is not necessary 
to refer to the encryption on/off field of the encryption payload 
header, and if information including notification of encryption 
is coded into the payload type field, this can be taken as a 

30 notification of the possibility of encryption, so that the 

encryption on/off field of the encryption payload header can be 
used for the final determination of whether or not there is 
encryption. 

35 Fifth Embodiment 

Next, the fifth embodiment of the present invention is 
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described below, with reference to Fig. 24 through Fig. 26, the 
description thereof focusing on the difference with respect to 
the second embodiment. 

Fig. 24 shows the format of the RTP header used when 
5 transmitting encrypted AV data in the fifth embodiment. Fig. 25 
shows the format of the encryption expansion header in the fifth 
embodiment, and Fig. 26 shows the overall IP packet transferred 
via the Internet in the fifth embodiment. 

Whereas in the second embodiment information including 

10 notification of encrypted data attributes (for example, encoding 
system) such as ""encrypted MPEG4" was coded into the payload type 
field within the RTP basic header (Fig. 11 and Fig. 12), in the 
fifth embodiment only information giving notification of the fact 
that the data is encrypted {for example, "encrypted data" ) is coded 

15 into the payload type header (Fig. 24 and Fig. 26) . While the 
addition of an encryption expansion header as an expansion header 
to the RTP header, and the provision of an MPEG4 expansion header 
as a payload header to the RTP payload are the same as with the 
second embodiment, in the fifth embodiment the above-noted 

20 encrypted data attributes (encoding system or the like) are coded 
into the encryption expansion header (Fig. 5 and Fig. 25). 

The overall configuration of the network according to the 
fifth embodiment is similar to that of an above-noted embodiment 
(Fig. 1), and the sequence of processing is also similar to an 

25 above-noted embodiment (Fig. 2) . The internal configurations of 
the MPEG4 distribution server 101 and the receiving apparatus 102 
are also similar to those of the second embodiment (Fig. 11 and 
Fig. 13). 

As shown inFig. 24, in the fifth embodiment a value indicating 
30 "encrypted data" is coded into the payload type field of the RTP 
basic header. The receiving apparatus 102 can refer this field 
to learn that the transferred data is encrypted. In the fifth 
embodiment, the X bit field has a bit that indicates "there is 
an expansion header". 
35 As shown in Fig. 25, in the fifth embodiment, a payload type 

field is provided in the encryption expansion header . Information 



30 



indicating the type of data {MPEG4 in this embodiment ) in the payload 
is coded into the payload type field. The receiving apparatus 
102 can refer to this field to learn the type of data transferred. 
In the receiving apparatus 102, at the RTF basic header 
5 receiver/interpreter 704 it is learned that the received data is 
encrypted data, and that there is an expansion header added to 
the RTF header. Then, at the encryption expansion header 
receiver/interpreter 706 is it learned that this expansion header 
is an encrypt ion expansion header , and from the encjrypt ion expansion 

10 header it is possible to learn such information as the encryption 
system, whether or not the encryption key is updated, and the type 
of data in the payload . Similar to the case of the second embodiment , 
the encrypted MPEG4 data is decrypted at the data 
encryptor/decryptor 707, the MPEG4 payload header is interpreted 

15 at the MFEG4 payload header receiver/ interpreter 715 , at the MPEG4 
data generator the MFEG4 data is decoded based on the results of 
the above interpretation, and the results are output as an AV output 
data (for example, an analog signal). 

In the fifth embodiment, similar to the case of the second 

20 embodiment , in the case in which information including notification 
of encryption is coded into the payload type field, it is not 
necessary to refer to the encryption on/off field of the encryption 
expansion header, and if information including notification of 
encryption is coded into the payload type field in the RTF basic 

25 header, this can be taken as a notification of the possibility 
of encryption, so that the encryption on/off field of the encryption 
expansion header can be used for the final determination of whether 
or not there is encryption. 

30 Sixth Embodiment 

Next, the sixth embodiment of the present invention is 
described below with reference to Fig. 27 and Fig, 28, the 
description focusing on the difference with respect to the fourth 
embodiment . 

35 Fig. 2 7 shows the format of the RTF header used when 

transmitting encrypted AV data in the sixth embodiment. The 
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encryption expansion header of this embodiment is similar to that 
shown in Fig. 25. Fig. 28 shows the overall format of an IP packet 
transferred via the Internet in the sixth embodiment. 

That both the encryption expansion header and the MPEG4 
5 expansion header are provided as an RTF payload header is similar 
to the fourth embodiment (Fig. 19 and Fig. 20) . However, in contrast 
to the fourth embodiment, wherein information including 
notification of attributes of encrypted data, such as the encoding 
system, for example, "encrypted MPEG4'' are coded into the payload 

10 type field within the RTP basic header, in the sixth embodiment, 
only information giving notification about the existence of 
encryption (such as "encrypted data") is coded into the payload 
type field (Fig. 27 and Fig, 28) . Additionally, while the fact 
that an encryption expansion header is added as an expansion header 

15 of the RTP header, and an MPEG4 expansion header is added as a 
payload header to the RTP payload are the same as in the second 
embodiment , in the sixth embodiment the above -noted encrypted data 
attributes (for example, encoding system) are coded within the 
encryption expansion header (Fig. 5 and Fig. 25) 

20 The overall configuration of the network according to the 

sixth embodiment is similar to an above-noted embodiment (Fig. 
1) , and the sequence of processing is also similar to an above-noted 
embodiment (Fig. 2). The internal configuration of the MPEG4 
distribution server 101 and the receiving apparatus 102 are also 

25 similar to those of the fourth embodiment (Fig. 18 and Fig. 22). 

As shown in Fig. 27 , in the sixth embodiment a value indicating 
"encrypted data" is entered into the payload type field of the 
RTP basic header. By referring to this field, the receiving 
apparatus 102 can know that the transferred data is encrypted data. 

30 The X bit field has a bit that indicates "there is no expansion 
header" . Similar to the case of the fourth embodiment , information 
indicating the type of data in the payload (MPEG4 in this embodiment) 
is coded into the payload type field of the encryption expansion 
header . 

35 In the receiving apparatus 102, at the RTP basic header 

receiver/ interpreter 704 it is learned that the received data is 
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encrypted, and it is learned that no expansion header is added 
to the RTF header. In the sixth embodiment, subsequent processing 
is with respect to the payload. First, at the encryption payload 
receiver/ interpreter 716 it is learned that the payload header 
5 is an encryption expansion header, and it is possible to learn 
from the encryption payload head such information as the encryption 
system, whether the encryption key is updated, and type of data 
in the payload. In the same manner as in the fourth embodiment, 
at the data encryptor/decryptor 707 the encrypted MPEG4 data is 

10 decrypted, at the MPEG payload header receiver/ interpreter 715 
theMPEG4 payload header is interpreted, at theMPEG4 data generator 
708 the MPEG4 data is decoded based on results of the above 
interpretation, the results being output as an AV output data (for 
example, an analog signal). 

15 In the sixth embodiment, similar to the case of the fourth 

embodiment, in the case in which information including notification 
of encryption is coded into the payload type field of the RTP basic 
header, it is not necessary to refer to the encryption on/off field 
in the encryption expansion header, and if information including 

20 notification of encryption is coded into the payload type field, 
this can be taken as a notification of the possibility of encryption, 
so that the encryption on/off field of the encryption expansion 
header can be used for the final determination of whether or not 
there is encryption. 

25 

S eve nth Embo dimen t 

Whereas in the first embodiment to the sixth embodiment, 
the present invention was applied to a system in which RTP was 
used as a transport protocol, the present invention can also be 

30 applied to systems using other protocols. 

In the seventh embodiment, instead of using RTP as the 
transport protocol, the distribution of MPEG4 data is performed 
using HTTP (Hyper-Text Transfer Protocol), that is, a protocol 
for use between WWW servers and Web browsers . 

35 Fig, 29 shows an example of the configuration of an 

information distribution system in the seventh embodiment. In 



33 



system shown in Fig. 29,. anMPEG4 distribution server 6101 according 
to the seventh embodiment is connected to the Internet 103, and 
a receiving apparatus 6102 according to the seventh embodiment 
is connected to a LAN 6105, the LAN 6105 being connected to the 
5 Internet 103 via a proxy server 6104. The receiving apparatus 
6102 performs AV stream communication secretly with the MPEG4 
distribution server 6101, via the LAN 6105, the proxy server 6104 
and the Internet 103 . Of course , other MPEG4 distribution servers 
and other types of equipment can also be connected to the Internet 

10 103, and other receiving apparatuses and other types of equipment 
can also be connected to the LAN 6105. 

Although in the seventh embodiment , the description is that 
of the case in which the data type is MPEG4, it will be understood, 
of course, that the present invention is not restricted to this 

15 type of data. 

In Fig. 29, the various equipment supports IP. However, 
because of the HTTP proxy server 6104 between the LAN 6105 and 
the Internet 103, the IP address on the LAN 6105 can be either 
a global IP address or a private (local) IP address. The term 

20 proxy server as used herein refers to a server that at one point 
terminates HTTP (or some other protocol) between the Internet and 
an intranet, and functions so as to join HTTP sessions at both 
ends of the proxy server, and is provided to enable the distribution 
of HTTP content data requested by substantial receiving apparatus 

25 (Web browser) to a distribution server (Web server) , and functions 
in the reverse direction as well. Details about proxy servers 
can be found at , for example, the URLhttp://squid. nlanr.net/Squid. 
In the seventh embodiment, the MPEG4 distribution server 6101 can 
be a WWW server, and the receiving apparatus 6102 can also be a 

30 browser. 

Fig. 30 shows an example of the sequence of the authentication 
process, key exchange process, and encrypted data transmission. 
Because the proxy server 6104 is disposed between the receiving 
apparatus 6102 and the MPEG4 distribution server 6101, the actual 
35 messages (messages transferred as HTTP messages) are in reality 
relayed via the proxy server 6104, this being the only difference 
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with respect to previously described embodiments (Fig. 2), with 
other elements of the procedure being the same as previously 
described procedures. 

With regard to the MPEG4 distribution server 6101, the 
receiving apparatus 6102, the packet format, if parts of the units 
in the first through the sixth embodiments dependent upon the 
transport protocol are modified to accommodate the HTTP protocol, 
it is possible to configure an MPEG4 distribution server 6101, 
a receiving apparatus 6102, and a packet format conforming to the 
HTTP protocol. In the following, the example is that in which 
an encryption expansion header is added as an expansion header, 
and in which an MPEG4 expansion header is provided as a pay load 
header (as in the second embodiment). 

Fig. 31 shows the internal configuration of the MPEG4 
distribution server 6101. 

As shown in Fig. 31, the MPEG4 distribution server 6101 
according to the seventh embodiment comprises an MPEG4 data 
generator 6301, a data encrypter 6302, an MPEG4 payload header 
adding unit 6305 , an HTTP processor 6303 that includes an encryption 
header adding unit 6304 and a MIME header adding unit 6306, a TCP/IP 
and UDP/IP processor 6308, a link/physical layer processor 6309, 
and an authentication/key exchange processor 6311. 

Processing related to authentication and encryption of the 
sequence shown in Fig. 30 (from S6201 to S6205) and processing 
related to encryption key updating is performed by the 
authentication/key exchange processor 6311. 

The HTTP processor 6303 corresponds to the RTP processor 
in previously described embodiments, and the MIME (Multipurpose 
Internet Mail Extensions) header adding unit 6306 corresponds to 
the RTP basic header adding unit in previously described 
embodiments . 

Fig. 32 shows an IP packet that is transferred on the Internet 
(and LAN), and Fig, 33 shows details of the MIME basic header and 
encryption expansion header. 

In the seventh embodiment, the encryption expansion header 
is transferred as part of the MIME. For this reason, with regard 
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to the encryption expansion header, information indicating that 
"this is an encryption expansion header" is coded into the 
Content-Type of the MIME. The MPEG4 expansion header is 
transferred as part of the MIME, along with the encrypted MPEG4 
5 data as pay load header. For the encrypted MPEG4 data to which 
MPEG4 expansion header added, information indicating that "this 
is MPEG4 data" is coded into the MIME Content -Type . For details 
with regard to MIME, refer to RFC 2045, for example. 

The format of the encryption expansion header is the same 
10 as was described for the first embodiment . 

Fig. 34 shows an example of the internal configuration of 
the receiving apparatus 6102. 

As shown in Fig. 34, the receiving apparatus 6102 according 
to the seventh embodiment comprises a link/physical layer processor 
15 6701, a TCP/IP and UDP/IP processor 6702, an HTTP processor 6703 
that includes a MIME header interpreter 6704 and an encryption 
header interpreter 6706, an MP EG 4 payload header interpreter 6705, 
a data encrypt or /decrypt or 6707, an MPEG4 data decoder 6708, and 
an authentication/key exchange processor 6711. 
20 Processing related to authentication and encryption in the 

sequence of Fig. 30 (processing from S6201 to S6205) and processing 
related to encryption key updating is performed by the 
authentication/key exchange processor 6711- 

The HTTP processor 6703 corresponds to the RTP processor 
25 shown in the above -de scribed embodiments, and the MIME header 
interpreter 6704 corresponds to the RTP basic header 
receiver/interpreter in the above -de scribed embodiments. 

In the MPEG4 distribution server 6101 , the inputted AV content 
(for example, an analog signal) is compressed to MPEG4 data by 
30 the MPEG4 data generator 6301. Required information is sent as 
notification to the MPEG4 payload header adding unit 6305 from 
the MPEG4 data generator 6301. 

Next , the MPEG4 data outputted from the MPEG4 data generator 
6301 is encrypted by the data encrypter 6302. The encryption key 
35 usedwhen doing this is the above -described time -variant encryption 
key Kc. Required information is sent as notification to the 



36 



iir <"!niiii(|i|i|^ii II II 



encryption header adding unit 6304 from the data encrypter 6302. 

Next, in the HTTP processor 6303, at the encryption header 
adding unit 6304, the encryption expansion header is added, and 
at the MIME header adding unit 6306, a MIME header is added. 
5 Encrypted MPEG4 data to which has been added a MIME header 

is sent as a packet shown in Fig. 32 to the Internet 610 3 by the 
TCP/IP and UDP/IP processor 6308, via the link/physical layer 
processor 6309. 

In the receiving apparatus 6102, at the MIME header 

10 interpreter 6704, it is learned that there is a possibility that 
the received data is encrypted, and that an encryption expansion 
header is added as part of the MIME. At the encryption header 
interpreter 6706 it can be learned from the encryption expansion 
header whether or not encryption is present , the encryption system 

15 and whether the encryption key is updated. In the same manner 
as in the case of the second embodiment, the data 
encrypt or /decrypt or 6707 decrypts the encrypted MPEG4 data, at 
the MPEG4 payload header interpreting section 6715 the MPEG4 pay load 
header ( similar to the MPEG4 payload header in previously described 

20 embodiments) is interpreted, and at the MPEG4 data generator 6708 
the MPEG4 data is decoded based on the results of the above 
interpretation, the result being output as an AV output data (for 
example, an analog signal). 

In the above, the encryption expansion header is added as 

25 an expansion header and the MPEG4 expansion header was provided 
as a payload header on the payload. However, it is also possible 
to use a different configuration, for example one in which the 
encryption expansion header and MPEG4 expansion header are added 
as an expansion header, or in which the encryption expansion header 

30 and MPEG4 expansion header are provided as a payload header on 
the payload. 

While in the first to seventh embodiments an Even/Odd field 
in the encryption expansion header (or encryption payload header) 
was used to notify the receiving side from the sending side of 
35 updating of the variable value Nc used for generating the encryption 
key Kc, instead of using the Even/Odd field, it is possible to 
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send the value of Nc, in which case the Nc value can be randomly 
generated, as opposed to simply being incremented. The value of 
Nc can also be changed for each individual packet. 

While in the first to seventh embodiments RTP or HTTP was 
5 used as the transfer protocol, it will be understood that other 
protocols can also be used, and further that the network to which 
the present invention is applied is not limited to the Internet. 
For example, any kinds of local area network, such as Bluetooth, 
can use the methods of this invention. Further, the present 
10 invention has no restriction in application to the case in which 
the transferred data is MPEG4 data. 

Although in the second, third, and fifth embodiments, the 
data encryptor 302 and data encrypt or/decryptor^70 7 were provided 
outside the RTP processors 303 and 307, these can alternately be 
15 provided within the RTP processors 303 and 307. 

Eighth Embodiment 

Next, the eighth embodiment of the present invention is 
described below with reference to Fig. 35. 
20 Whereas in the first to the seventh embodiments, the 

description was for the sequence shown in Fig, 2, it is understood 
that the present invention can be applied to other sequences as 
well. 

The description that follows is for other sequences, for 
25 the case in which MPEG4 data distributed from an MPEG4 distribution 
server is stored by the receiving apparatus. 

The configuration of the information distribution system 
according to the eighth embodiment is similar to that shown in 
Fig. 1 . In Fig. 1 , an MPEG4 distribution server 101 and a receiving 
30 apparatus 102 according to the eighth embodiment are connected 
to the Internet 103, MPEG4 AV stream data being secretly 
communicated between the MPEG4 distribution server 101 and the 
receiving apparatus 102, via the Internet 103. Of course, other 
MPEG4 distribution servers and receiving apparatuses and other 
35 types of equipment can additionally be connected to the Internet 
103. 
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In the description of the eighth embodiment, while the type 
of data is MPEG4, it will be understood that the eighth embodiment 
is not restricted to application to this type of data, and can 
be applied to other data types as well. 
5 The MPEG4 distribution server 101 performs distribution of 

MPEG4 data to the receiving apparatus 102, MPEG4 data is 
distributed not in the form of file transfer, but rather as a stream. 
When this is done, the MPEG4 data that is to be copyright protected 
is distributed in encrypted form. Before distribution, an 
10 authentication procedure or key exchange procedure is performed 
between the MPEG4 distribution server 101 and the receiving 
apparatus 102. 

13 An example of the sequence used is shown in Fig, 35. 

In Fig. 35 shows the sequence of content layer encryption 
y 15 and authentication, and it should be noted that security in layers 

i^Oi such as the IP layer and transport layer and authentication 

fz procedures in those layers have been omitted from this drawing, 

i!p as has the procedure for assessing charges at the content layer, 

s which is performed earlier { although there are cases in which charge 

20 assessment and authentication/encryption at other layers are not 
ui performed) . 

13 Similar to the case of the first embodiment, the MPEG4 

y distribution server 101 and the receiving apparatus 102 perform 

""^ authentication and exchange of a certificate (equipment 

25 certificate) {S7201, S7202) . 

The MPEG4 distribution server 101 must notify the receiving 
apparatus 102 of the encryption key Kc for decrypting the content 
( AV data that is sent ) , and the following measure is taken to prevent 
the unlimited unauthorized copying of the content at the receiving 
30 apparatus 102. Specifically, when performing storage onto a 
storage medium (for example, a DVD-RAM) of the receiving apparatus 
102, AV data is stored in encrypted form. When the data stored 
on the storage medium is to be played back, a check is made as 
to whether the data was properly stored on the storage medium and, 
35 if not, playback is not possible. That is, if digital copying 
is done from this storage medium onto another storage medium (for 
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example, onto another DV-RAM) , playback is prevented from the 
copying destination medium. 

For this reason, notification of the MID, which is the ID 
(serial number) of the storage medium used at the receiving 

5 apparatus 102 is given from the receiving apparatus 102 to the 
MPEG4 distribution server 101 (step S7203), and at the MPEG4 
distribution server 101 this MID value is used to encrypt the 
encryption key Kc and notify the receiving apparatus 102 (step 
S7204). More specifically, using a pre-established function g 

10 an encryption key W is generated of the form W=g{MID), and this 
encryption key W is used to encrypt the encryption key Kc (the 
encryption key Kc encrypted by the encryption key W being 
represented as [Kc]w), [Kc]w being then transmitted. In this 
arrangement , the value of MID is unique to each individual storage 

15 medium, and is located in a region of ROM, for example, that cannot 
be overwritten. 

Having received the above-noted [Kc]w, the receiving 
apparatus 102 generates the encryption key W in the form W=g(MID) , 
using the same function g that was used at the MPEG4 distribution 

20 server 101, this encryption key W being used to decrypt [Kc]w so 
as to recover the encryption key Kc. 

Thereaf ter, at the MPEG4 distribution server 101 MPEG4 data 
is generated from the AV data, and MPEG4 data is encrypted using 
the encryption key Kc shared as described above, the encrypted 

25 MPEG4 data being then transmitted to the receiving apparatus 102 
(step S7206) . 

At the receiving apparatus 102 , the received encrypted MPEG4 
data is decrypted using the encryption key Kc determined as noted 
above and decrypted MPEG4 data is decoded, resulting in output 

30 of an AV output data. 

In the eighth embodiment, the receiving apparatus 102 has 
a function which, simultaneously with receiving the AV data (MPEG4 
data encrypted with the encryption key Kc), or after entering it 
into a buffer or the like , stores the received AV data in the form 

35 of MPEG4 data encrypted using the encryption key Kc, along with 
the value of [Kc]w, onto a storage medium having the above-noted 
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MID, 

When the above is done, an apparatus for playing back the 
AV data (MPEG4 data encrypted with the encryption key Kc) stored 
on the proper storage medium (which can be the receiving apparatus 
5 102, or another equipment) first reads the values of [Kc]w and 
MID from the storage medium, and then generates the encryption 
key W in the form W=g(MID), this encryption key W being used to 
decrypt [Kc]w so as to recover the encryption key Kc, Then the 
AV data (MPEG4 data encrypted by the encryption key Kc) stored 

10 on the storage medium is read out and, after decrypting with the 
encryption key Kc, the decrypted MPEG4 data is decoded. 

If AV data (MPEG4 data encrypted by the encryption key Kc) 
recorded on a storage medium having a given MID'of MIDI is copied 
onto a storage medium having a MID of MID2, at the equipment that 

15 plays back the data recorded on the copy destination storage medium , 
because it is not possible to obtain the original MID value, it 
is not possible to generate W, and therefore not possible to 
determine the encryption key Kc from the recorded [Kc]w. As a 
result, it is not possible to decrypt the recorded encrypted data. 

20 That is, if proper values of Kc, W, and [Kc]w are Kcl, 

Wl=g{MIDl), and [Kc]wl, because the MID read out from the copy 
destination storage medium is MID2 , the encryption key W generated 
therefrom is W2=g(MID2) and if the [Kc]wl read from the storage 
medium is decrypted using W2, a value that is different from Kc 

25 results (this being called Kc' ) . Therefore, an attempt to decrypt 
data [Data]Kc encrypted with Kc using Kc' will result in generation 
of Data' , which is different from the original data Data, making 
it impossible to recover the original data Data. 

Thus, even if the received AV data (MPEG4 data encrypted 

30 by the encryption key Kc) is copied onto a different storage medium, 
because the value of MID of that storage medium is different, it 
is possible to prevent playback of the AV data, thereby enabling 
prevention of unauthorized copying. 

In the eighth embodiment, the RTP header, encryption 

35 expansion (payload) header, and MPEG4 expansion (payload) header 
and the like can have the same format as described with regard 



41 



mil ••[ immn 



In 
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to the first through the seventh embodiinents. 

Although the above-noted description is for the case in which 
MPEG4 was used as the encoding system, it will be understood that 
the present invention can be applied to other encoding systems 
5 as well, in which case it is merely necessary to modify the 
constituent elements of each of the embodiments (for example, the 
MPEG4 data generator, the MPEG4 expansion header adding unit, the 
MPEG4 data decoder, the MPEG4 expansion header 
receiver/ interpreter, and the like) , the expansion header (MPEG4 
10 expansion header and MPEG4 payload header) , and the payload type 
coding to suit the selected type of encoding system. 

The distribution server of the described embodiments, if i 
necessary, can also be made to send content in unencrypted form. 
That is, the coding of the encryption on/off field and payload 
15 type field and the like can be established as appropriate to the 
existence or non-existence of encryption. The receiving side as 
well can check for the presence of encryption from the header of 
a received packet, and control decryption processing accordingly. 
The transport protocol used in the foregoing embodiments 
20 includes at least RTP or HTTP. 

The present invention can also be embodied as a method and 
a method according to the present invention can be embodied as 
an apparatus. Additionally, the functions of the present 
invention can be embodied as software as well. 
25 The present invention embodied as either an apparatus or 

a method can be further embodied as a computer -readable storage 
mediiam for storage of a program to be executed by a computer, 
following a procedure corresponding to the present invention (or 
a program for causing a computer to function as a means corresponding 
30 to the present invention or a program for implementing the functions 
of the present invention with a computer). That is, a program 
for the purpose of implementing the processing for content 
distribution and receiving according to the present invention can 
be stored onto various types of storage media. The storage medium 
35 is then read by the CPU of a computer implemented in hardware, 
and the stored program is then executed to embody the present 
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invention. The term storage medium used herein can be taken as 
referring to semiconductor memory, magnetic disk (floppy disk or 
hard disk) , optical disk (CD-ROM or DVD or the like) , and any other 
medium that can be used to store a program. Additionally, the 
5 program can be distributed by various communications means, such 
as a network. 

In summary, according to the present invention an encryption 
expansion header is provided in the form of a expansion header 
or pay load header in a transport protocol such as RTP (Real-time 

10 Transport Protocol) or HTTP (Hyper-text Transfer Protocol), and 
encryption attribute information with regard to encryption is coded 
into this enciryption expansion header (for example, presence of 
encryption, encryption system, information with regard to copying 
(encryption mode indicator: EMI), infoxmation (Even/Odd field) 

15 on which to base generation of a content key (common key) and the 
like ) , and by doing so content data is sent securely from the sending 
side to the receiving side, and it is possible at the receiving 
side to decrypt the encrypted content data transferred as a payload . 
In RTP in the past, only the type of encoding system used 

20 with data of the payload was coded in the payload type field, so 
that in the case in which the data stored in the payload was encrypted 
not in at the network or transporter layer , but rather at the content 
layer, there was no method of giving notification of this to the 
other side. 

25 On the other hand , with the present invention , because coding 

is provided in the RTP payload type field to the effect that the 
content is "encrypted data" or "encrypted data encoded by a specif ic 
encoding system", it is possible to give notification of this to 
the other side, thereby enabling sufficient copy protection in 

30 sending and receiving encrypted content as described above. 

According to the present invention as described above, it 
is possible to expand the distribution of digital content , providing 
copy protection for AV streaming that covers not only IEEE 1394, 
but also networks such as the Internet and LAN. 

35 It is to be noted that , besides those already mentioned above , 

many modifications and variations of the above embodiments may 



43 



be made without departing from the noel and advantageous features 
of the present invention. Accordingly, all such modifications 
and variations are intended to be included within the scope of 
the appended claims. 
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What is claimed is: 

1. A content information distribution apparatus for 
distributing encrypted content information, via a network in 
5 accordance with a prescribed transport protocol, to other end 
apparatus in a communication authenticated by an authentication 
process including at least one procedure of an authentication 
procedure and a key exchange procedure, comprising: 

(a) a unit (302) for encrypting content information encoded 
10 by a prescribed encoding system; 

(b) a unit (304) for generating an encryption attribute header 
including attribute information with regard to the encryption of 
the content information; 

(c) a unit (306) for performing transport protocol processing 
15 required to transfer the content information and for generating 

a basic transport header to be added to the content information 
to which the encryption attribute header has been added; and 

(d) a unit (for sending to the other end apparatus that is 
authenticated a packet including the basic transport header, the 

20 encryption attribute header , and the encrypted content information , 
wherein the encryption attribute header is set into an expansion 
transport header within a packet header of the packet or into a 
payload header within a payload to be encirypted of the packet. 

25 2, The apparatus according to claim 1, wherein the encryption 
attribute header includes at least one of the existence or 
non-existence of encryption of the content information and the 
encryption system of the content information. 

30 3. The apparatus according to claim 1, wherein the encryption 
attribute header includes a copy attribute field having a plurality 
of bits with regard to the number of copying of the content 
inf onnation. 

35 4. The apparatus according to claim 1, wherein the encryption 
attribute header includes a counter field indicating a change in 
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an encryption key. 

5. The apparatus according to claim 1, wherein the unit (b) 
sets the encoding information, which indicates the encoding system 

5 for the content information into the expansion transport header 
or into the pay load header. 

6, The apparatus according to claim 1, wherein the unit (c) 
further codes into the basic transport header at least information 

10 indicating that there is a possibility that the content information 
is encrypted, and wherein the unit (b) codes into the expansion 
header at least information as to whether or not the content 
information to be transferred is encrypted, 

15 7. The apparatus according to claim 1, wherein the unit (b) 
codes into the expansion header information as to whether or not 
the content information to be transferred is encrypted. 

8. The apparatus according to claim 1, further comprising: 
20 (e) a unit for generating a content attribute header that 

includes content attribute information with regard to content 
information, and for setting this content attribute header into 
the expansion transport header or into the payload header. 

25 9, The apparatus according to claim 8, wherein the content 
attribute header is not encrypted. 

10. The apparatus according to claim 1, wherein the unit (a) 
generates the encryption key based on an identifier that uniquely 

30 identifies a storage medium sent from the other end apparatus in 
a communication. 

11 . A content information receiving apparatus authenticated by 
an authentication process including at least one procedure of an 

35 authentication procedure and a key exchange procedure and which 
receives encrypted content information via a network in accordance 
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with a prescribed transport protocol, comprising: 

(aa) a unit for receiving from a sending apparatus a packet 
containing a basic transport header, an encryption attribute header 
including attribute information with regard to the encryption of 
the content information, and encrypted content information ; 

(bb) a unit for referring to the basic transport header or 
encryption attribute header and judging whether or not the content 
information is encrypted or whether there is a possibility that 
the content information is encrypted; and 

(cc) a unit that, when a judgment is made by the unit (bb) 
that the content information is encrypted, decrypts the encrypted 
content information, based on the attribute information with regard 
to encryption included in the encryption attribute header. 

12. The apparatus according to claim 11, wherein the unit (bb) , 
when there is a possibility that the content information is 
encrypted, refers to the encryption attribute header and judges 
whether or not the content information is encrypted. 

13.. The apparatus according to claim 11, wherein the unit (bb) 
refers to the basic transport header or to the encryption attribute 
header to make a judgment as to the encoding system of the content 
information. 



14. The apparatus according to claim 11, further comprising: 
(dd) a unit for referring to a received basic transport header 
and, when a prescribed delay time has elapsed or a prescribed number 
of packets have been discarded, requesting that the sending 
apparatus send a prescribed encryption parameter. 

15 . A method of distributing encrypted content information, via 
a network in accordance with a prescribed transport protocol , to 
other end apparatus in a communication authenticated by an 
authentication process including at least one procedure of an 
authentication procedure and a key exchange procedure, comprising 
the steps of : 
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(a) encrypting content information encoded by a prescribed 
encoding system; 

(b) adding an encryption attribute header including 
attribute information with regard to the encryption of the content 
information to the encrypted content information; 

(c) adding a content attribute header indicating attributes 
of the content information to content information to which the 
encryption attribute header has been added; 

(d) performing transport protocol processing required to 
transfer the content information, and adding a basic transport 
header to content information to which the content attribute header 
has been added; and 

(e) sending a packet including the basic transport header, 
the encryption attribute header, the content attribute header, 
and the encrypted content information to the other end authenticated 
apparatus , 

wherein the encryption attribute header is set into either 
an expansion transport header within a packet header of the packet , 
or into a payload header within an encrypted pay load of the packet , 

16 • A method of distributing encrypted content information, via 
a network in accordance with a prescribed transport protocol, to 
other end apparatus in a communication authenticated by an 
authentication process including at least one procedure of an 
authentication procedure and a key exchange procedure, comprising 
the steps of: 

{ a ' ) adding a content attribute header indicating attributes 
of the content information to the content information to be 
transferred; 

(b') encrypting content information that are encoded by a 
prescribed encoding system and to which the content attribute header 
has been added; 

(c') adding to the encrypted content information an 
encryption attribute header including attribution information 
with regard to the encryption of the content information; 

(d') performing transport protocol processing required to 
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transfer the content information, and adding a basic transport 
header to content information to which the encryption attribute 
header has been added; and 

(e' ) sending a packet including the basic transport header, 
5 the encryption attribute header, the content attribute header, 
and the encrypted content information to the other end authenticated 
apparatus , 

wherein the encryption attribute header is set into either 
an expansion transport header within a packet header of the packet , 
10 or into a payload header within a payload to be encrypted of the 
packet - 

17. A method of receiving encrypted content'^ informat ion , via 
a network in accordance with a prescribed transport protocol, by 
15 an authentication process including at least one procedure of an 
authentication procedure and a key exchange procedure, comprising 
the steps of : 

(aa) receiving a packet including a basic transport header, 
an encryption attribute header including encryption attribute 
20 information with regard to the encryption of the content information , 
and encrypted content information; 

(bb) referring to the basic transport header and judging 
whether or not the content information is encrypted or whether 
or not there is a possibility that the content information is 
25 encrypted; 

(cc) referring to the encryption attribute header and 
extracting encryption attribute information with regard to 
encryption of the content information; 

(dd) referring to an expansion transport header within a 
30 packet header of the packet and extracting content attribute 
information with regard to the content information; and 

(ee) in the case in which a judgment is made at (bb) that 
the content information is encrypted, decrypting the encrypted 
content information, based on the extracted encryption attribute 
35 information. 
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18- A method of receiving encrypted content information, via 
a network in accordance with a prescribed transport protocol, by 
an authentication process including at least one procedure of an 
authentication procedure and a key exchange procedure, comprising 
5 the steps of: 

(aa' ) receiving a packet including a basic transport header, 
an encryption attribute header including encryption attribute 
information with regard to the encryption of the content information, 
and encrypted content information; 
10 (bb* ) referring to the basic transport header and judging 

whether or not the content information is encrypted or whether 
or not there is a possibility that the content information is 
encrypted; 

(cc' ) in the case in which a judgment is made at (bb' ) that 
15 the content information is encrypted, referring to the encryption 
attribute header and extracting encryption attribute information 
with regard to the encryption of the content information; 

(dd' ) in the case in which a judgment is made at (bb' ) that 
the content information is encrypted, decrypting the encrypted 
20 content information based on the extracted encryption attribute 
information; and 

(ee' ) referring to an expansion transport header within a 
packet header of the packet and extracting content attribute 
information with regard to the content information. 

25 

19 . A computer-readable recording medium for recording a program 
to be executed by a computer, the program performing distribution 
of encrypted content information, via a network in accordance with 
a prescribed transport protocol, to other end apparatus in a 
30 communication authenticated by an authentication process 

including at least one procedure of an authentication procedure 
and a key exchange procedure, the program comprising: 

(a) a module for generating an encryption attribute header 
including attribute information with regard to encryption of the 

35 content information ; 

(b) a module for performing transport protocol processing 
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required to transfer the content information and for generating 
a basic transport header to be added to the content information 
to which the encryption attribute header has been added; and 
(c) a module for sending a packet including the basic 
5 transport header, the encryption attribute header, and the ^ 
encrypted content information to the other end authenticated 
apparatus , 

wherein the encryption attribute header is set either into 
an expansion transport header within a packet header of the packet 
10 or into a payload header within a payload to be encrypted of the 
packet • 

20 • A computer- readable recording medium for recording a program 
to be executed by a computer, the program perfonning receiving 

15 of encrypted content information, via a network in accordance with 
a prescribed transport protocol, by an authentication process 
including at least one procedure of an authentication procedure 
and a key exchange procedure, the program comprising: 

(aa) a module for receiving from a sending apparatus a packet 

20 including a basic transport header , an encryption attribute header 
including attribute information with regard to encryption of the 
content information, and encrypted content information; 

(bb) a module for referring to the basic transport header 
or the encryption attribute header and judging whether or not the 

25 content information is encrypted or whether there is a possibility 
that the content information is encrypted; and 

(cc) a module for decrypting the encrypted content 
information based on attribute information with regard to 
encryption included in the encryption attribute header, in the 

30 case in which a judgment is made by module (bb) that the content 
information is encrypted. 
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ABSTRACT OF THE DISCLOSURE 

A content distribution apparatus for implementing copy 
protection when distributing digital content as a real-time stream 
5 on the Internet is provided. This apparatus encrypts content and 
distributes them to a receiving apparatus via the Internet, and 
performs an authentication procedure and a key exchange procedure 
between with the receiving apparatus . The encoded content encoded 
by a prescribed encoding system is encrypted, an encryption 

10 expansion header is generated that includes at least one attribute 
information of attribute information indicating whether or not 
the content is encrypted and attribute information indicating the 
encryption system used, transport protocol processing required 
to transfer the content is performed and a basic transport header 

15 is generated , a packet being sent which includes the basic transport 
header, the encryption expansion header , and the encrypted content . 
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As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated 
next to my name, 

I believe I am the original, first and sole inventor (if only one 
name is listed below) or an original, first and joint inventor (if 
plural names are listed below) of the subject matter which is 
claimed and for which a patent is sought on the invention 
entitled. 

COISITEISIT DISTRIBUTION APPAE^TUS, CDNTEaSTT 
RECEIVING APPAE?ATUS, AND CX)NTE3S[T DISTRIBUTl|ON 

METHOD 

the specification of which 
H is attached hereto. 

□ was filed on 



as United States Application Number or 
PCT Intemational Application Number 

and was amended on 

(if applicable). 
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I hereby state that I have reviewed and understand the 
contents of the above identified specification, including the 
claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose information which is material 
to patentability as defined in Title 37, Code of Federal 
Regulations, Section 1 .56. 
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I hereby claim foreign priority under Trtle 35, United States Code, 
Section 119 (a)-(d) or 365(b) of any foreign app{ication(s) for patent 
or inventor's certificate, or Section 365(a) of any PCT international 
application which designated at least one country other than the 
United States, listed below and have also Identified betow, by 
checking the box, any foreign application for patent or inventor's 
certificate, or PCT International application having a filing date 
before that of the application on which priority is claimed. 

Priority Claimed 



31 /March/ 1999 



(Day/MonthA'ear Filed) 
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(Day/MontiVYear Filed) 
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I hereby claim the benefit under Title 35, United States Code, 
Section 11 9(e) of any United States provisional appllcation(s) listed 
below. 



(Application No.) 



(Filing Date) 
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I hereby daim the benefit under Trtle 35, United States Code. Section 
120 of any United States application(s), or Section 365(c) of any PCT 
Intemational application designating the United States, listed below 
and, insofar as the subject matter of each of the claims of this 
application is not disclosed in the prior United States or PCT 
Intemational application in the manner provided by the first paragraph 
of Trtle 35, United States Code Section 112,! acknowledge the duty 
to disdose information which is material to patentability as defined in 
Trtle 37, Code of Federal Regulations, Section 1.56 which became 
available between the filing date of the prior application and the 
national or PCT IntematbnaJ filing date of application. 



(Status: Patented. Pending, Abandoned) 



(Status: Patented, Pending, Abandoned) 

I hereby declare that all statements made herein of my own 
knowledge are true and that all statements made on information 
and belief are believed to be true; and further that these statements 
were made with the knowledge that willful false statements and the 
like so made are punishable by fine or imprisonment, or both, under 
Section 1001 of Trtle 18 of the United States Code and that such 
willful false statements may jeopardize the validity of the application 
or any patent issued thereon, 
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Residence 
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Citizenship 
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Corporation, 1-1-1, Shibaura, Minato-ku, 
Tokyo, Japan 






(Supply similar information and signature for third and subsequent 
joint inventors.) 
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Japanese Language Declaration 





Full name of third joint inventor, if any 

XCnilTO i\JFHJU/i 






TliirdJoint Inventor;^ signature^ Date 

/ Jz' <^:^X^t^-^/^ March 23. 200C 


im 


Residence 

Tokyo , Japan 


mm 


Citizenship 
Japan 




Post Office Address 
c/o Intellectual Property Division, Toshiba 




Corporation, 1-1-1, Shibaiira, Minato-ku, 
Tokyo, Japan 





Full name of fourth joint inventor, if any 

Yoshiaki TAKABATAKE 




'K^^Z'^iSS:^/./.? «ar^°23, 200C 




Residence 

Kanagawa, Japan 


mm 


Citizenship 
Japan 




Post Office Address 
c/o Intellectiial Property Division, Toshiba 




Corporation, 1-1-1, Shibaixra, Minato-ku, 
Tokyo f Japan 





Full name of f ifthjoint inventor, if any 
Junko AMI 




Fifth joint Inventor's signature . Date_^ 




Residence 

Kanacrawa, Japan 




Citizenship 
Japan 




Post Office Address 
c/o Intellectual Propertv Division, Toshiba 




Corporation, 1-1-1, Shibaura, Minato-ku, 
Tokyo, Japan 





Full name of sixth joint inventor, if any 




Sixth joint Inventor's signature Date 


im 


Residence 


mm 


Citizenship 




Post Office Address 







(^T^ttz it^tllUf^O^^^^^^^^^M b T =fe)fR]+i4^+S (Supply similar information and signature for third and sub- 

$g;te J: Xfm^ ^ ffifftT ^^to) ^^^"^"^ inventors.) 
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